Important: Record Level Security permissions

In order to be able to change Record Level Security settings for a record, a user must possess the typical Operations permissions that allow for editing of records (e.g. daEdit): without the daEdit permission, a user cannot edit records.

Two other conditions must also be met however. The user must possess (or be a member of a group that possesses) the following:

• The daSecurity permission.
• The Record Level Security Edit permission for the record: the Edit checkbox on a record's Security tab must be ticked:

  

  Understanding the Permissions checkboxes

  Checkbox	Description
  	A permission inherited from another group. Faded and uneditable. To change this permission for the selected user / group, change it in the group from which it has been inherited.
  	A permission assigned to this user / group. This permission can be unassigned by clicking the checkbox.
  	An unassigned permission. Can be assigned to this user / group.

Without these two permissions, Record Level Security options on a record's Security tab will be uneditable.

It is worth reiterating that Record Level Security permissions are additional to the base operations permissions. Possessing the Record Level Security Edit permission to a record is not sufficient to be able to edit the record. The user must possess the daEdit permission in the first instance.

It is also important to keep in mind that users inherit permissions from the groups to which they belong.

Users inherit permissions from groups

First a simple illustration. As the name suggests, all users are members of group Everyone. Let us give Everyone permission to Edit this record:

Now when we check the permissions for the Admin group we find that not only is the Display permission uneditable, but so is Edit:

To remove the Edit permission from group Admin, we would first need to remove it from group Everyone.

Tip: If your objective is to remove permissions for a user / group and you find that a permission is uneditable, the user / group probably inherited the permission from another group added to the Security box.

Greater detail: users inherit permissions from groups

For this demonstration, the default group Everyone has the Display permission for a record:

When user gerard is added to the Security box he inherits the Display permission (which is faded out and uneditable) as he is a member of group Everyone:

Note: Technically, the minimum permission a user / group has is the Display permission (a user / group added to the Security box will always already have the Display permission by virtue of being added to the Security box).

User gerard can be given both Edit and Delete permissions (as they are not inherited from group Everyone in this example). In this case we only want to give user gerard the Edit permission, but not Delete:

User gerard is also a member of group Managers, which is now added to the Security box. This group has both Edit and Delete permissions:

User gerard inherits permissions from all groups to which he belongs when those groups are added to the Security box, and now we see that he has the Delete permission which we did not want him to have:

If we only wanted user gerard to have Edit permissions but wanted other members of group Managers to have Edit and Delete, one solution would be to remove user gerard from group Managers.

Note: If you wish to restrict access to a record, be sure to remove group Everyone from the Security box.